A similar change (plus the line session.setSystemProperties(System.getProperties());) could be done in the SessionBuilderSupplier for Maven4. But I assume this is better done in Maven-4 directly, isn't it?

Personally, I'd skip doing this altogether and here is why:

• as i see in Maven4 supplier (plus Maven side of bits) this is not happening at all
• the goal of supplier is to provide "baseline" only, and nothing in Resolver uses ENV variables
• the idea is that user who needs env or whatever, just customize supplier by overriding required method

* the goal of supplier is to provide "baseline" only, and nothing in Resolver uses ENV variables

I understand that. But the problem can be and that's why I encountered this at all, is that some artifacts cannot be resolved some system properties are missing.
For example without any system-properties, org.apache.commons:commons-text:1.12.0 fails to resolve with a ModelBuildingException saying something like [ERROR] Failed to determine Java version for profile. In this case the java.version property is missing and e.g. the animal-sniffer profile from the commons-parent cannot determine if the activation element <jdk>(,9)</jdk> is met or not. And since properties and env-properties can also be used to activate profiles in general and profiles can contain additional dependencies, not having them can influence the resolution result.
A general property activation will probably not fail the resolution if a property is missing (I haven't tested it), but the result would still be different than in a default maven installation. So the resolver could implicitly use env variablies.
But I cannot tell if the latter already is already out of the scope of the baseline?

Superseded by #724

Resolve #1262